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(57) Abstract: The present invention includes a merchant system (105) that recognizes virtually any payment device (120) or tech- 
Q nology that uses electronic check processing as a payment mechanism. For example, the merchant system (105) associates presenta- 

tion of the payment device (120) with information used to electronically debit a checking account, such as MICR data, and submits 
^ the same to a transaction processor (115) capable of settling electronic debit transactions. 
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ALTERNATIVE PAYMENT DEVICES USING ELECTRONIC CHECK PROCESSING AS A PAYMENT 

MECHANISM 

FIELD OF THE INVENTION 
The present invention relates to the field of electronic commercial transactions. More specifically, 
the invention relates to merchant systems designed to recognize alternative payment devices that use 
electronic check processing as a payment mechanism. 

BACKGROUND OF THE INVENTION 
Consumers and merchants in today's marketplace have access to a wide variety of technologies for 
extending credit or otherwise transferring monies for goods or services ("products"). For example, consumer 
and merchants use traditional debit technologies such as paper checks. A check refers to a draft or order for 
a certain sum of money payable on demand to a certain named entity, the entity's order, or to the bearer 
thereof. Generally, the face of a check includes magnetic ink character recognition ("MICR") characters that 
can be read electronically. The MICR characters typically include a checking account number, the bank 
transit number, the check sequence number, and the like. In addition, the MICR characters may indicate 
whether the check is a company check or a personal check. The form or font of the MICR characters and 
their position along the bottom edge of the check are generally prescribed by standards promulgated by the 
American National Standards Institute ("ANSI"), which are incorporated by reference herein. 

Paper checks are generally processed through clearinghouse ( U ACH°) networks, which can include 
some or all banks, clearinghouse corporations, the Federal Reserve bank, or the like. For example, a payor, 
or check writer, may authorize an originator, such as a grocery store, to debit the payor's checking account by 
writing a check for, for example, groceries. The originator forwards the authorization to an originating 
depository financial institution ("ODFI"), such as the grocer's bank. The ODFI sends the authorization through 
the ACH network to a receiving depository financial institution ("RDFI"), such as the payor's bank. The RDFI 
then can transfer funds by debiting the payor's checking account and sending a credit through the ACH 
network to the ODFI, or grocer's bank. 

To avoid many drawbacks associated with the foregoing paper check processing, such as 
processing delays measured in many days and sometimes in one or more weeks, ACH networks now provide 
for electronic check processing. For example, merchants can now have personal checks converted to 
electronic ACH debits, often by scanning in paper check data at the point-of-sale, and returning the paper 
copy of the check to the consumer. The paper check data generally includes data representing the MICR 
characters, an amount, a payee, a scan of one or both sides of the paper check, and the like. As can be 
expected, the electronic ACH debits can be processed at much greater speeds due at least in part to the lack 
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The decreased processing delays associated with the electronic ACH debits often advantageously 
provide more consistent deposit patterns back to merchants and decrease the delay in discovering and 
stoppmg the use of fraudulent checks. Additionally, as discussed in the foregoing, electronic ACH debits also 
advantageously allow merchants to immediately return the paper check to the customer. 

Other technologies available to consumers and merchants in today's marketplace include traditional 
credrt and debit card technologies. While these traditional card technologies enjoy wide acceptance as a 
method of paying for products both in modem online and traditional paper processing environments, they 
have significant drawbacks for consumers and for merchants. For example, as compared with the banking 
population, a much smaller percentage of consumers have or use one or more credit or debit cards 
Moreover, the issuer of card technologies often charges high interest rates to the consumer, while also 
charging high fixed or high variable processing fees to merchants. The high rates often render smaller 
mcremental charges viatraditionalcardtechnotogies impractical. Also, more and more consumers are unable 
or unwilling to pay down their debt, so they resort to revolving that debt from one credit card to the next In 
addition to the foregoing, traditional card technologies can be subject to fraud, fines, or the like. 

Still other technologies available today include modem payment technologies, such as, convenience 
or loyalty cards, radio frequency payment devices such as Easypay, Speedpass, Fastpay, toll road 
transponders, or the like. Generally, a consumer first enrolls in a payment technology with a merchant or a 
gateway service. During enrollment, the consumer often provides a credit or debit card account from which 
deb.ts w.11 be made. The merchant then issues, for example, the payment device to the consumer When the 
consumer desiras to purchase products from the merchant the consumer presents the payment device to for 
example, a receiver device designed to communicate with the payment device so as to uniquely identify'the 
consumer's associated credit or debft card account. The merchant then bills the consumer's card for the 
25 purchase of the products. 

The foregoing payment technologies are finding wider acceptance among consumers as the 
payment technologies often provide a very convenient payment mechanism, and are finding wider acceptance 
among merchants as payment technologies often generate consumer loyalty. However, because the 
foregomg payment technologies often employ traditional card technologies as the backend payment 
30 mechanism, these payment technologies unfortunately assume many or all of the foregoing drawbacks 
assocated with the traditional card technologies, including, for example, the inability to practically service 
smaller, incremental-type charges. 
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SUMMARY OF THE INVENTION 
Based at least in part on the foregoing drawbacks, a need exists for transaction processing system 
that allows consumers to use modem payment technologies without incorporating the drawbacks of traditional 
credit or debit card technologies. One embodiment of the invention includes a transaction processing system 
5 that converts a transaction produced from virtually any payment device or technology, into electronic debits 
processed through clearinghouse systems as traditional electronic ACH debits to a checking account. Thus, 
the transaction processing system advantageously avoids the negative drawbacks of traditional credit or debit 
card technologies while incorporating the advantages of electronic ACH debit processing. Moreover, by using 
a checking account for the debit, the transaction processing system advantageously uses the most prevalent 
10 financial account found in the U.S. population. According to some embodiments, the transaction processing 
system also provides for the guarantee of payment to the merchant or retailer initiating the transactions. 

According to one embodiment, the transaction processing system includes a merchant system, a 
transaction processor, an automated clearinghouse system and a user account. The transaction processor 
accepts enrollment transaction requests from merchant systems seeking to issue a payment device to a new 
15 user, where the payment device is other than apaper check and designed to access debit funds in the user's 
checking account For example, the payment device can include cards, transponders, biometric elements, or 
the like. During enrollment processing, the transaction processor accepts user data, MICR data, the check 
number, and the like. The transaction processor also accepts a transaction date and merchant data, such as 
a merchant's identification number or other data. 
20 According to one embodiment, the transaction processor processes enrollment transaction requests 

by validating some or all of the user data, by clearing some or all of the user data through negative and/or 
positive databases, assessing a risk score to the enrollment transaction using, for example, a variety of payor 
historical payment variables as well as variables associated with typical transactions in that standard industry 
code (SIC - a four digit code often used to denote differing specific industries), validating MICR data through 
25 ACH processing, or the like. The transaction processor returns a result of the enrollment transaction to the 
merchant. According to one embodiment, the result can include advice on whether to an accept or decline 
the user, an assessed risk score associated with enrolling the user, a result of a negative and/or positive 
database search, some or all of the same, or the like. 

According to another embodiment, the transaction processor also accepts purchase transaction 
30 requests from merchant systems that have recognized a payment device presented by a user as payment for 
a product. For example, the merchant system can associate a presented payment device with a unique user 
account directing the merchant to withdraw funds to cover payment from the user's checking account. The 
merchant system organizes the information into a purchase transaction request and forwards the same to the 
transaction processor. During the processing of purchase transactions, the transaction processor accepts 
35 data, such as some or all of the foregoing user data, some or all of the foregoing MICR data, some or all of 
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FIGURE 4 illustrates a purchase process, according to an embodiment of the invention. 

FIGURE 5 illustrates a transaction processing process, according to an embodiment of the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
5 A transaction processing system converts the presentation of virtually any payment device or 

technology, into electronic debits to a checking account processed through a clearinghouse system. Thus, 
the transaction processing system advantageously avoids the negative drawbacks of traditional credit or debit 
card technologies while incorporating the advantages of electronic debit processing. Moreover, by using a 
checking account, the transaction processing system uses the most prevalent financial account found in the 
10 banking population. 

As will be apparent, many of the disclosed features may be used without others, and may be 
implemented differently than described herein. Further, although described primarily in the context of a 
transponder based system, the various inventive features are also applicable to types of alternative payment 
devices other than paper checks or credit or debit cards, including, but not limited to loyalty cards, electronic 
15 wallets, one or more smart cards, one or more biometric elements such as a thumbprint or facial recognition, 
other point-of-sale payment devices, or the like. The following description is thus intended to illustrate, and 
not limit, the invention. 

According to one embodiment, the transaction processing system includes a merchant system, a 
transaction processor, a user payment device, a clearinghouse system, and a user debit account. The 

20 transaction processor accepts enrollment transaction requests from merchant systems seeking to issue a 
payment device to a new user, such as a potential payor, where the payment device is other than a paper 
check and designed to access debit funds in the user's debit account, such as a checking account. For 
example, the user can include an individual consumer attempting to make a financial transaction. The 
payment device can comprise a convenience or loyalty card, a transponder, such as radio or other frequency 

25 transponder, an electronic wallet, one or more smart cards, one or more biometric elements such as a 
thumbprint or facial recognition, other point-of-sale payment devices, or the like. During enrollment 
processing, the transaction processor accepts user data, such as driver's license number or other 
identification information, demographic information such as name, address, birth date, telephone number, 
social security number, or the like, one or more biometric measurements, passwords, or the like. The 

30 transaction processor also accepts MICR data such as scanned or manually entered MICR characters from 
an unused paper check of the user, the check number, or the like. The transaction processor also accepts a 
transaction time, place and date, and merchant data, such as a merchant's identification number, location, or 
other data. 

35 ENROLLMENT TRANSACTIONS 
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The merchant may also choose to have the transaction processor validate any ACH processing data. 
According to one embodiment, the transaction processor can perform a validation transaction where a user's 
checking account is debited and credited for, for example, an equal amount. The result of such debiting and 
crediting can be reported through, for example, settlement files similar to those to be discussed with reference 
5 to purchase transactions. The foregoing validation transactions ensure that the user's account and the 
associated banking institutions are compatible with the processing of electronic ACH debits. 

PURCHASE TRANSACTIONS 

According to another embodiment, the transaction processor also accepts purchase transaction 
10 requests from merchant systems that have recognized a payment device presented by a user as payment for 
a product. The merchant system associates the device with a unique account directing the merchant to 
withdraw funds to cover payment from the user's debit account. During purchase processing, the transaction 
processor accepts data, such as some or all of the foregoing user data, some or all of the foregoing MICR 
data, some or all of the foregoing merchant data, or the like. The transaction processor also accepts data 
1 5 related to the specific transaction, such as product information, amount of purchase, time of day, day of week, 
date, location of purchase, purchaser, cash back amount, type of payment device, and the like. The 
transaction processor also organizes and submits one or more electronic ACH debits associated with the 
transaction to the clearinghouse system. 

Moreover, in an embodiment similar to that disclosed with reference to enrollment transaction 
20 requests, the transaction processor processes transaction requests by validating some or all of the submitted 
user data, by clearing some or all of the user data through negative and/or positive databases, by assessing a 
risk score to the enrollment transaction, by settlement through electronic ACH debit processing, or the like. 
The transaction processor returns an authorization result of the purchase transaction, to the merchant. As 
disclosed in the foregoing, the format and content of various information within the authorization result may 
25 depend on whether the transaction processor will act as a guarantor for the payment transaction. As 
disclosed, the authorization result can include advice or instructions on whether to an accept or decline the 
purchase transaction, a risk score to inform the merchant of a risk associated with accepting the transaction, a 
result of a negative and/or database search, or the like. 

When the transaction processor processes purchase transaction requests that include settlement, 
30 the transaction processor can send a report, often in the form of a settlement file, to the merchant. For 
example, when the transaction processor processes one or more (e.g., a batch of) transactions, the 
transaction processor may send a preliminary settlement report which is often subject to reversal. Similar to 
paper check processing, electronic check processing often assumes that transactions are settled, but then 
reverses a transaction when debits and/or credits fail during processing by a clearinghouse system, such as 
35 the ACH. The foregoing settlement file may be sent after one or more transactions have been processed, one 
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105 submits a purchase transaction request and submits the purchase transaction request to the transaction 
processor 115. The transaction processor 115 performs various merchant-selected services, such as those 
disclosed in the foregoing, and returns an authorization result to the merchant system 105. Depending upon 
the authorization result, the merchant system 105 may complete the purchase by providing the products to 
the user and informing the transaction processor 115 of the same. The transaction processor 115 then 
advantageously performs settlement through the issuance of one or more electronic ACH debit transactions to 
the clearinghouse system 125, thereby transferring funds from the debit account 130 to a credited account 
135, such as, for example, the merchant's bank account. 

According to embodiments where the user payment device 120 communicates through, for example, 
a wireless signal, the merchant system 105 may include a merchant receiver 140 designed to receive the 
foregoing communications. 

MERCHANT SYSTEM 105 

According to one embodiment, the merchant system 105 includes the components be used to 
implement a system which uniquely identifies a debit account when a user presents payment devices other 
than paper checks or credit cards. For example, the merchant system 105 may include one or more central 
server systems 142, which can communicate with one or more merchant receivers 140, one or more user 
account databases 144 and with electronic documents 146. The user account databases 144 can store 
various user data including MICR data which can be used to identify the debit account 130, and the 
associated device identifier ( U ID R ) the merchant system 105 will use to recognize the user payment device 
120. For example, as described in the foregoing with respect to enrollment, the user can provide MICR data 
from a check that corresponds to the account from which funds are to be drawn, such as, for example, the 
debit account 130. The MICR data can include a routing or bank transit number, generally identifying the 
financial institution or groups of financial institutions that issued the original user's check, an account number 
against which the original check is drawn, a check sequence number, various separator symbols often unique 
to the financial institution, and the like. In addition, the MICR data can indicate whether the check is a 
company check or a personal check. The device ID can include an identification number or account number 
which uniquely identifies each user's debit account 130, which may also be used by the server 142 to index 
other data in the user account databases 1 44. 

The user account database 144 may also; include user enrollment data, such as the name, email, 
address, login identifier, password, or the like of each user. The information may also include historical data 
fore each user, such as transactions, purchases, payments, risk scores, credit histories or other financial 
information, public record data, or the like. 
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USER ENROLLMENT SYSTEM 110 

FIGURE 1 also shows the transaction processing system 100 comprising the user enrollment system 
110. According to one embodiment, the user enrollment system 110 comprises one or more computer 
systems allowing a user to interact with the merchant system 105 via a communication link. In one 
5 embodiment, the computer is equipped with a modem or other communication device configured to 
communicate with aspects of the merchant system- 105. The computer may comprise, by way of example, 
processors, program logic, or other substrate configurations representing data and instructions, which operate 
as described herein. In other embodiments, the processors can comprise controller circuitry, processor 
circuitry, processors, general purpose single-chip or multi-chip microprocessors, digital signal processors, 
10 embedded microprocessors, microcontrollers and the like. In addition, the user enrollment system 110 can 
comprise a computer workstation, a local area network of individual computers, a kiosk, a point-of-sale 
device, a personal digital assistant, an interactive wireless communications device, an interactive television, a 
transponder, or the like. 

In one embodiment, the user employs the user enrollment system 110 to enroll with the merchant 

15 system 105. For example, the merchant system 105 may advantageously present an electronic enrollment 
form to the user through the user enrollment system 110. The enrollment form can include an entry for data 
associated with the debit account the user wishes to tie to the payment device 120, such as, for example, 
MICR data from an unused check. According to one embodiment, the enrollment form may also include an 
explicit authorization from the user, authorizing the merchant, the processor, or both, to generate electronic 
, 20 debits and credits from a selected user debit account. 

When the user has completed the enrollment form, the user enrollment system 110 transfers the 
entered information to the merchant system 105, where it is stored, for example, in the user account database 
144. An exemplary enrollment process is disclosed with reference to FIGURE 3. 

Although the enrollment system 110 is disclosed with reference to an embodiment of Internet 

25 enrollment, the invention is not intended to be limited thereby. Rather, as disclosed, a wide number of 
alternative systems can provide user enrollment, such as, for example, user enrollment via the mail, a 
telephone call, a facsimile, or the like. Often, the enrollment vehicle options are limited by rules of the 
financial institutions governing portions of the transaction, such as, for example, rules generated by NACHA 
for the national ACH network. 

30 FIGURE 1 also shows the merchant system 105 including server code 148. The server code 148 

advantageously includes one or more software processes or program logic designed to execute on the server 
systems 142. In one embodiment, the server code 148 may advantageously include software or hardware 
components such as software object-oriented components, class components and task components, 
processes methods, functions, attributes, procedures, subroutines, segments of program code, drivers, 

35 firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. As illustrated in 
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risk scoring, account information validation, settlement processing, or the like. The transaction process code 
also returns enrollment and authorization results. As disclosed, various information within the authorization 
result may depend on whether the transaction processor will act as a guarantor for the payment transaction. 
As disclosed, the authorization result can include advice or instructions on whether to an accept or decline the 
payment transaction, a risk score to inform the merchant of a risk associated with accepting the transaction, a 
result of a negative and/or database search, or the like. 

USER PAYMENT DEVICE 120 

As disclosed in the foregoing, the user payment device 120 allows users to make purchases by 
presenting the device 120 to the merchant system 105, and having the appropriate funds withdrawn from the 
debit account 130. According to one embodiment, the user payment device 120 can comprise a wide variety 
of point-of-sale payment devices. For example, the user payment device 120 can comprise radio or other 
frequency transponders, such as toll transponders designed to automatically communicate with tollbooths, 
thereby avoiding the need to stop and pay cash to use a toll road. The user payment device 120 may 
comprise transponders designed to communicate with gas stations for the payment of fuel at the pump. 
Transponders may be used to conveniently pay for drive through services, grocer checkout counters, or 
virtually any place where payment through a wireless device makes for convenient, efficient, purchases. 
According to one embodiment, the user payment device 120 can comprise a computing device, a personal 
digital assistant, a wireless telephone or the like. Moreover, according to one embodiment, the user payment 
device 120 transmits various data when it detects the presence of a receiver for the same. Other 
embodiments may include the ability to receive data from or otherwise communicate with, for example, the 
merchant system 105. 

According to another embodiment, the user payment device 120 may comprise loyalty cards such as 
those used by many grocers, or the like. In such embodiments, the user payment device 120 may include a 
magnetic stripe and/or number designed to uniquely identify the debit account 130. According to yet another 
embodiment, the user payment device 120 may comprise biometric solutions such as those used by quick 
serve restaurants including thumbprints, facial recognition, or the like. Other embodiments include electronic 
wallets, one or more smart cards, or the like. 

As disclosed in the foregoing, the user payment device 120 can advantageously be associated with 
the merchant, and therefore, can often generate loyalty in customers as they desire to use their device 
instead of carrying cash or using expensive credit card technologies. 

CLEARING HOUSE NETWORK 125 

According to one embodiment, the clearinghouse system 125 comprises the national ACH network. 
Generally, the ACH network can accept electronic ACH debit and credit transactions against, for example, the 
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for automated processing through the clearinghouse system 125, which is generally significantly less 
expensive than the minimum fixed cost fees associated with the traditional card technologies. 

Although the transaction processing system 100 has been disclosed with respect to various 
preferred and alternative embodiments, an artisan will recognize from the disclosure herein that a wide 
number of differing devices can accomplish the functionality disclosed. For example, the merchant system 
105 and the transaction processor 115 may advantageously be governed by, and/or comprise a single entity 
or system. Moreover, layered gateway systems may offer users the ability to use the gateway's payment 
device in multiple retail locations of multiple merchants, without departing from the scope of the present 
disclosure. 

EXEMPLARY ENROLLMENT FORM 

FIGURE 2 illustrates an exemplary webpage 200, which can be used to enroll the user into the 
transaction processing system 100, according to an embodiment of the invention. As shown in FIGURE 2, 
the webpage 200 comprises user demographic information 205, such as name, address, email, age, social 
security number, gender, or other historical or demographic information desired by the merchant or processor 
to, among other things, develop accurate risk assessments of the user. The webpage 200 also includes an 
account selection button 210, providing the user the ability to associate, for example, payments from the user 
device 120, to the debit account 130. According to one embodiment, the user can select his or her checking 
account. According to other embodiments, the user may select a credit card or other financial accounts. 

When the user desires to tie his or her payment device 120 to the debit account 130, the webpage 
200 also includes an entry section for entry of debit account data 215. As shown in FIGURE 2, the debit 
account data 215 can include MICR data from an unused check. According to one embodiment, the user may 
be prompted to enter an asterisk (*), or other placeholder character, in place of the non-numeric symbols that 
are included in many MICR characters printed on a check. Alternatively, the webpage 200 may include an 
interactive portion which allows users to select from a given set of non-numeric MICR symbols to be added to 
their MICR data. Other embodiments may include instructions on how to create and/or attach a scanned 
image of an unused check, or a file containing data from a MICR line optical and/or magnetic reader. In such 
embodiments, the merchant or the processor may incorporate hardware and/or software components 
designed to interact with such data to extract the MICR data, such as, for example, optical character 
recognition ("OCR") software, or the like. As shown in FIGURE 2, the webpage 200 may request MICR data 
be entered twice, thereby advantageously allowing the merchant system 105 to compare each entry so as to 
ensure correct entry thereof. 

Embodiments of the enrollment webpage 200 also include an authorization section 220, where the 
user explicitly authorizes the merchant system 105 and/or the transaction processor 115 to perform electronic 
ACH debit and credit transactions to his or her selected debit account Such authorization may include a 
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120 as payment for products. As disclosed in the foregoing, such authorization can be governed by rules 
promulgated by the clearinghouse system 125. 

At BLOCK 320, the merchant system 105 organizes various user-submitted information into an 
enrollment transaction request, and submits the same to the transaction processor 1 15. The form and format 
of the enrollment transaction request can be designated or defined by the merchant system 105 and/or 
transaction processor 115, and according to one embodiment, can include information identifying the 
merchant, identifying the user, date and time information, information designating the user's account data, 
such as MICR data, merchant information, or the like. The enrollment transaction request may also include 
additional information useful in assessing the risk of the user, such as, for example, a driver's license or social 
security number, address, credit card data, or other demographic or financial data. 

After the transaction processor 115 processes the enrollment transaction, such as, for example, 
according to various disclosed merchant-selected services, the transaction processor returns an enrollment 
result. According to embodiments disclosed herein, the enrollment result provides an indication to the 
merchant system 110 of the risk associated with accepting the enrollment of the user in the transaction 
processing system 100. 

At BLOCK 325, the merchant system 105 confirms the receipt of that result, and can further instruct 
the transaction processor 1 15 to validate the enrolling user's account information. For example, the merchant 
system 105 may desire to ensure that the banks, financial institutions, or the like, associated with the debit 
account 130, support the submission of electronic ACH debit transactions. According to one embodiment, the 
merchant system 105 instructs the transaction processor 115 to format and submit an electronic ACH debit 
and credit for equal amounts against the debit account 130, thereby validating that the account information 
supports electronic ACH processing. 

At BLOCK 330, the merchant system 105 receives the report from the transaction processor 115 
detailing, for example, the results of the validation of account information, the risk associated with enrolling 
the user, permission to enroll the user in embodiments where the transaction processor 115 acts as a 
guarantor, one or more settlement files, or the like. Upon receipt of the report, the merchant system 105 can 
advantageously determine whether to enroll the user into the transaction processing system 100. 

Based on the foregoing, the enrollment process 300 advantageously provides assurances to the 
merchant system 105 on whether the enrolling user is within an acceptable credit risk and whether the user- 
selected debit account 130 and associated banking institutions allow for electronic transactions through the 
clearinghouse system 1 25. 

Although disclosed with reference to preferred and alternative embodiments, an artisan will 
recognize from the disclosure herein that the enrollment process 300 may advantageously include portions or 
all of the foregoing functionality, without departing from the spirit or scope of aspects of the invention. 
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authorization results and transmits an indication to the transaction processor 115 that the purchase was 
finalized and settlement should be processed. 

According to one embodiment, the transaction processor 115 uses the MICR conversion data from 
the MICR conversion database 156, to translate the MICR data into that information desired by the 
clearinghouse system 125. The transaction processor 1 15 then formats and submits an electronic ACH debit 
which includes the foregoing information, to the clearinghouse system 125. 

Based on the foregoing, the purchase process 400 advantageously advises, and often guarantees 
that the purchase transaction is within an acceptable credit risk for the merchant. Moreover, the purchase 
process 400 performs settlement processing. Although disclosed with reference to preferred and alternative 
embodiments, an artisan will recognize from the disclosure herein that the purchase process 400 may 
advantageously include portions or all of the foregoing functionality, without departing from the spirit or scope 
of aspects of the invention. 

TRANSACTION PROCESS 

FIGURE 5 illustrates a transaction processing process 500, according to an embodiment of the 
invention. As shown in FIGURE 5, the transaction processing process 500 generally includes the transaction 
processor 115 receiving one of an enrollment transaction request or a purchase transaction request from the 
merchant system 105. Based on which services the merchant selected, the transaction processing process 
500 performs various levels of risk assessment and, in some cases, may guarantee the transaction. Thus, 
according to one embodiment, the actions of the transaction processing process 500 will vary depending upon 
the service selections of the merchant. The transaction processing process 500 also can validate various 
account information and/or perform settlement processing through communication with the clearinghouse 
system 125. 

According to one embodiment, the transaction processing process 500 begins at BLOCK 505 where 
the transaction processor receives one of an enrollment transaction request or a purchase transaction request 
from the merchant system 105. As described in the foregoing, when the merchant-selected services include 
one or more of user data validation, clearance of the negative and positive databases, assessment of risk 
scores, or the like, the transaction processor 115 performs those activities with respect to the information 
provided in the particular transaction request, as illustrated in BLOCKS 510-520 of FIGURE 5. 

At BLOCK 525, the transaction processor 115 transmits the results of the foregoing processing back 
to the merchant system 105. As described, at BLOCK 530, the merchant system 105 confirms the receipt of 
the transaction results, and instructs the transaction processor 115 to validate the account data associated 
with an enrollment transaction request, settle the purchase associated with a purchase transaction request, or 
the like. 
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1. A financial transaction system configured to accept as payment for goods or services the 
presentation by a payor of a payment device other than a paper check, a credit card or a debit card, the 

5 financial transaction system comprising: 

a payment device other than a paper check, a credit card or a debit card, where 
presentation of the payment device for goods or services indicates that funds are to be drawn on a 
checking account of a payor to pay for the goods or services in an electronic transaction; 

a point of sale device which receives from the payment device, identification data useable 
10 to uniquely identify the payment device; and 

one of more computing devices that assess risk wherein the one or more computing 
devices assess the risk of the electronic transaction, and accept or decline the payment for the 
goods and services. 

2. The financial transaction system of Claim 1, wherein the payment device comprises a 
15 transponder. 

3. The financial transaction system of Claim 1 , wherein the payment device comprises one or 
more loyalty cards. 

4. The financial transaction system of Claim 1 , wherein the payment device comprises one or 
more smart cards. 

20 5. The financial transaction system: of Claim 1, wherein the payment device comprises a 

computing device. 

6. The financial transaction system of Claim 5, wherein the payment device comprises a 
personal digital assistant. 

7. The financial transaction system of Claim 1, wherein the payment device comprises a 
25 mobile telephone. 

8. The financial transaction system of Claim 1, wherein the payment device comprises one or 
more biometric elements. 

9. The financial transaction system of Claim 1, wherein the payment device comprises one or 
more devices storing or using biometric data. 

30 10. The financial transaction system of Claim 1, wherein the point of sale device comprises a 

wireless receiver. 

11. The financial transaction system of Claim 1, wherein the point of sale device comprises a 
magnetic strip reader. 
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22. The method of Claim 21, further comprising enrolling the user by issuing the payment 
device and obtaining the checking account data. 

23. The method of Claim 22, further comprising obtaining an assessment of a risk of enrolling 

the user. 

24. The method of Claim 22 further comprising acquiring information identifying the user 
attempting to enroll into a system providing for the payment goods or services from the checking account of 
the user through the presentation of the payment device. 

25. The method of Claim 24, wherein the information includes information found on the user's 
driver's license. 

26. The method of Claim 24, wherein the information includes demographic information. 

27. The method of Claim 24 wherein the information includes biometric information. 

28. The method of Claim 24, wherein the information includes password information. 

29. The method of Claim 21, wherein the assessment of the risk is acquired through a 
transaction processor. 

30. The method of Claim 21 wherein obtaining the assessment of risk is based on one or more 
characteristics of the electronic transaction 

31 . The method of Claim 30 wherein the checking account information comprises MICR data. 

32. The method of Claim 31, wherein the one or more characteristics of the electronic 
transaction include whether the MICR data is valid. 

33. The method of Claim 31, wherein the MICR data is valid when it can be converted into 
information used by clearinghouse systems to transfer funds. 

34. The method of Claim 30, wherein the one or more characteristics of the electronic 
transaction include whether an assessed risk of the electronic transaction is within predetermined parameters. 

35. The method of Claim 34, wherein the assessed risk includes an evaluation of historical 
transaction information. 

36. The method of Claim 35, wherein the historical transaction information includes negative 
transaction information. 

37. The method of Claim 35, wherein the historical transaction information includes positive 
transaction information. 

38. The method of Claim 30, wherein the one or more characteristics of the electronic 
transaction include whether the electronic transaction will be guaranteed. 

39. The method of Claim 21 , further comprising transmitting MICR data to a gateway system. 

40. The method of Claim 21, further comprising transmitting information to a gateway system, 
and wherein the gateway system determines whether to accept or decline the electronic transaction. 

41 . The method of Claim 21 , wherein the payment device comprises a transponder. 
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